Anforderungen an eine Architektur zur Integrationsunterstützung in dynamischen Kooperationen aus Sicht der Bauwirtschaft

Dynamische Entwicklungen in Unternehmensnetzwerken und deren Umwelt erfordern eine flexible IT-Architektur, die es ermöglicht, auf variable Bedingungen zu reagieren. Dieser Beitrag diskutiert Anforderungen an eine integrative Architektur, die das Management, die Modellierung von Geschäftsprozessen und Kooperationsstrukturen sowie die Prozessausführung betreffen. Als Anwendungsdomäne dient die Baubranche, die mit projektartigen Netzwerken und immanenten Änderungen eine hohe Dynamik aufweist. Die Anforderungen wurden zum einen aus einer theoretischen Betrachtung des DynamikBegriffs und dessen Auswirkungen auf Kooperationen erschlossen. Zum anderen wurde eine Befragung von Experten aus Wissenschaft und Praxis zur Erhebung domänenspezifischer Anforderungen durchgeführt. 1 Motivation und Zielsetzung Die Bildung von Unternehmensnetzwerken ist eine Reaktion auf die zunehmende Globalisierung der Wirtschaft. In der Literatur haben sich einige Theorien zur Kooperationsbildung etabliert, wie bspw. die Transaktionskostentheorie, der market-based view, der resource-based view oder die Spieltheorie. Projektartige Netzwerke sowie sich verändernde Marktbedingungen führen zu einer erhöhten Dynamik der Geschäftsprozesse [1]. Daraus ergeben sich besondere Herausforderungen an die Gestaltung der Informationssystemarchitektur, die zur Integration der am Wertschöpfungsprozess beteiligten Partner herangezogen wird. Dieser Beitrag diskutiert Anforderungen an eine Architektur zur Integrationsunterstützung in dynamischen Kooperationen und zeigt exemplarische Lösungsansätze für einzelne Probleme. Als Anwendungsdomäne dient die Baubranche, die mit ihren projektartigen Unternehmensnetzwerken, wechselnden Beteiligten und immanenten Planungsänderungen den dynamischen Aspekt von Unternehmensnetzwerken geeignet widerspiegelt. Hierbei werden mehrere Anforderungsebenen betrachtet, die in einem integrativen Gesamtkonzept vereint werden. Kapitel 2 diskutiert zunächst allgemeine Anforderungen an kooperative Architekturen. Kapitel 3 untersucht den Begriff der Dynamik und zeigt deren Auswirkungen auf die IT. Kapitel 4 stellt Ergebnisse einer Expertenbefragung aus der Domäne der Bauwirtschaft dar. Kapitel 5 zeigt ausgewählte Lösungsansätze. Schließlich fasst Kapitel 6 die Ergebnisse zusammen und gibt einen Ausblick auf weitere Schritte. 2 Allgemeine Anforderungen an Integrationsarchitekturen In der Literatur existiert eine Vielzahl von Ansätzen, die Architekturen für Unternehmensnetzwerke und Geschäftsprozessmanagement diskutieren. Häufig genannte Anforderungen sind im Bereich der Sicherheit und des Vertrauens anzusiedeln [2-5], wie bspw. eine sichere Transaktionsabwicklung oder die Abbildung von Rollen. Diskutiert wird auch die Flexibilität, die eine einfache Applikationsund DV-Integration, eine Selbstorganisation der Architektur sowie die Skalierbarkeit der Systeme umfasst [3, 68]. Die Wiederverwendbarkeit der benutzten Komponenten [6, 9] und die Integration der verwendeten Modellierungssprachen unter Schaffung eines einheitlichen Begriffsverständnisses [3, 10] sind weitere Erfordernisse an die Architektur. Whitescarver et al. [5] erheben weitergehende Anforderungen aus verschiedenen Frameworks für sozio-psychologische Kollaboration, Organisation und Kommunikation, User Interfaces, Netzwerkinfrastrukturen und Metatools. Bemängelter Punkt in klassischen EAILösungen ist das Fehlen geeigneter Monitoring-Instrumente, die integrationsweite Analysen für Entscheidungsträger zur Verfügung stellen [7, 11]. Ein möglicher Ansatz zur Erfüllung der genannten Anforderungen ist die Integration durch Portale mit einheitlichen Benutzeroberflächen, indem sie Werkzeuge zur Teamund Projektarbeit oder zur kollaborativen Prozessabarbeitung anbieten. Portale sollen sowohl unstrukturierte Informationen wie Dokumente oder Grafiken als auch strukturierte Informationen wie Transaktionsdaten, Analysen und Auswertungen verfügbar machen [12]. Einige Ansätze zur Verwendung von Portalen wurden jedoch aus vielerlei Gründen in der betrachteten Domäne nicht akzeptiert. 3 Dynamik und ihre Auswirkungen auf die IT Dynamik bezeichnet in der Systemtheorie, deren Ansatz im Weiteren verfolgt wird, die Bewegung in einem System bzw. den Anpassungsprozess zur Erhaltung eines Systemgleichgewichts [13]. Die Eigendynamik beschreibt Veränderungen, die von endogenen Faktoren verursacht werden. Dies sind insbesondere systeminterne Ziele, Bedürfnisse und Zwänge, die bspw. durch veränderte Machtund Einflussfaktoren oder Strategieänderungen hervorgerufen werden. Die Umfelddynamik beschreibt Veränderungen, die von exogenen Faktoren verursacht werden. Diese Umweltfaktoren sind vom Netzwerk nicht beeinflussbar, wie bspw. politisch-rechtliche, sozioökonomische oder technologische Rahmenbedingungen, welche die Kooperation sowohl fördern als auch einschränken können. Auf die exogenen Faktoren kann nur durch prozessuale oder strukturelle Änderungen reagiert werden. Erkennbar ist ein Zusammenhang zwischen exogenen und endogenen Faktoren. So führen exogene Faktoren bspw. zu neuen Strukturen im Netzwerk, die sich wiederum auf die Prozesse im Netzwerk auswirken [14]. Insbesondere bei Unternehmensnetzwerken, die strukturellen Veränderungen unterliegen, sind gleichzeitig die Prozessstrukturen zu verändern. Diese Strukturveränderungen können ihrerseits durch Prozessveränderungen hervorgerufen werden, so dass eine Interdependenz von Prozess und Struktur erkennbar ist [15]. Der hier dargestellte Zusammenhang zwischen endogenen und exogenen Faktoren sowie Strukturen und Prozessen wird in Abbildung 1 zusammengeführt. Abbildung 1. Der Dynamikbegriff in Netzwerken Wesentliche Anforderung, die sich aus der Dynamik ergibt, ist die Flexibilität. Der optimale Grad der Flexibilität ist insbesondere von der Dynamik der exogenen Faktoren abhängig. Hieraus resultieren bspw. die Festlegung und Abbildung von Früherkennungsindikatoren für die Rekonfiguration oder Auflösung des Unternehmensnetzwerks, die Vorbereitung der Aufnahmeentscheidung eines neuen Partners oder die Koordination der Planung von Kooperationsentwicklungsstrategien [16, 17]. Weiterhin ist zu berücksichtigen, dass auf Grund der sich ändernden Prozesse und Strukturen eine Adaption von Modellen und eine Ad-hoc-Abarbeitung von Prozessen gewährleistet werden muss. Dies impliziert, dass aus technologischer Sicht verschiedene operative Systeme flexibel zu integrieren sind. 4 Anforderungen aus der Anwendungsdomäne Im Rahmen einer Befragung von Experten aus Wissenschaft und Bauwirtschaft wurden Aspekte ermittelt, die bei der Integration vorhandener Konzepte und der Verbesserung abzubildender Geschäftsprozesse in der Bauwirtschaft zu berücksichtigen sind. Besonders häufig werden Anforderungen im Bereich der Integration genannt. Zum einen werden unterschiedliche Formate für technische Zeichnungen und Pläne verwendet, die zeitnah und aktuell den Unternehmen zur Verfügung stehen müssen. Zum anderen existieren in der Baubranche Merkmalsdaten sowie Leistungsund Produktkataloge, die zur Modellierung und expliziten Beschreibung von Leistungen herangezogen werden. Merkmalsdaten sind Metadaten für Leistungsund Produktkataloge. Sie strukturieren und definieren Kataloginhalte auf Basis von Merkmalen und Merkmalsausprägungen. Leistungskataloge spezifizieren alle Leistungen, die in der Baubranche erbracht werden können (Output). Sie dienen als Referenzdaten für die Leistungsbeschreibung eines Bauprojekts und strukturieren materielle Sachleistungen sowie immaterielle Dienstleistungen (etwa 100 Millionen Leistungen). Sie sind standardisiert (DIN 18299 ff.) und gelten im Rahmen der Vergabeund Vertragsordnung für Bauleistungen (VOB) als verbindliche Richtlinie (VOB, Teil A, § 9 Nr. 3(4)). Demzufolge müssen sie in operative Systeme zur Planung, Kalkulation oder Beschaffung integrierbar sowie netzwerkweit für jedes Unternehmen verfügbar sein. Produktkataloge beschreiben herstellerneutrale Referenzprodukte mittels konkreter Produkteigenschaften. Hierbei handelt es sich um Materialien, die zur Erstellung von Bauwerken verwendet werden (Input). Sie müssen insbesondere während der Kalkulation sowohl für das Gesamtprojekt als auch für einzelne Netzwerkpartner zur Verfügung stehen. Zur Zeit existiert noch kein standardisierter Produktkatalog für die Baubranche, jedoch gibt es erste Bestrebungen in diese Richtung, wie bspw. das Projekt bau:class zur Erarbeitung einer Klassifikation für Baustoffe und Bauprodukte [18]. Leistungskataloge und Produktkataloge dienen als Referenzdaten für projektspezifisch zu erstellende Leistungsverzeichnisse und Vergabeeinheiten. Ein Leistungsverzeichnis listet die konkreten Teilleistungen und Ausführungsbeschreibungen eines Bauprojekts auf. Es ist Grundlage für die Kommunikation und Basis für die Ausschreibung, Vergabe und Abrechnung (AVA) im Rahmen eines Bauprojektes. Das Leistungsverzeichnis wird i. d. R. zentral von einem Planer erstellt und liefert eine Gesamtübersicht über die zu erbringenden Leistungen. Die Vergabeeinheiten sind ähnlich strukturiert, beschreiben aber lediglich die zu erbringenden Leistungen eines einzelnen Unternehmens. Dieses Verzeichnis muss sowohl dem Planer als auch dem Unternehmen selbst in geeigneter Weise zugänglich gemacht werden. Für eine medienbruchfreie Nutzung dieser Daten muss ein standardisierter Datenaustausch der Leistungsund Produktdaten ermöglicht werden. Auf Basis der Leistungsbeschreibung muss ein netzwerkweites Prozessmanagement etabliert werden. Die Leistungsbeschreibung kann als Grundlage für die Modellierung von Geschäftsprozessen dienen. Einzelne Prozesse werden durch die Vergabeeinheiten eindeutig einem Unternehmen innerhalb des Netzwerks zugeordnet. Es muss gewährleistet sein, dass jedes einzelne Unternehmen Informationen darüber erhält, von welchem Unternehmen die eigene Leistungserbringung abhängt bzw. wer im Gesamtprozess direkt abhängig von der eigenen Leistung ist (Vorgänger/Nachfolger). Die Architektur muss demzufolge die unternehmensübergreifende Modellierung von Geschäftsprozessen unterstützen. Zu beachten ist, dass unterschiedliche Modellierungsmethoden sowohl bei den Netzwerkpartnern als auch auf verschiedenen Ebenen verwendet werden. Es sind verschiedene Perspektiven und Abstraktionsstufen zu berücksichtigen: Auf Management-Ebene werden fachkonzeptionelle, stark abstrahierte und semiformale Modelle verwendet, während zu Simulationszwecken und zur Fehlererkennung stärker detaillierte und formalisierte Modelle Anwendung finden. Hierzu sind geeignete Konverter zu definieren, die eine Transformation semiformaler Modelle in formale Modelle ermöglichen. Weiterhin muss gewährleistet sein, dass aus Sicht des Unternehmensnetzwerks das Wissen über den Zusammenhang von Leistungen und Prozessen sowie über abstrakte Prozesse vorhanden ist (globales Wissen). Detaillierte Informationen über die Prozesse stellen teilweise Geschäftsgeheimnisse der individuellen Unternehmen dar und sind dagegen nur lokal vorzuhalten (lokales Wissen) [19]. Für die Modelle müssen geeignete Speicherund Zugriffsmechanismen zur Verfügung stehen, die gleichzeitig ein Versionsmanagement der Modelle unterstützen. Zur Schaffung eines kooperationsweiten Begriffsverständnisses sind einheitliche Konventionen zu spezifizieren. Aus Sicht des Managements kooperativer Geschäftsprozesse müssen sowohl die Vorplanung von Prozessen zur Build-Time eines Bauprojekts als auch die ständige Kontrolle von laufenden Prozessen zur Run-Time unterstützt werden. Dies betrifft die Analyse, Simulation und Optimierung sowie die Berücksichtigung von Ad-hocProzessen. Für laufende Prozesse müssen Kennzahlen zugänglich sein, um ein kooperationsweites Monitoring zu ermöglichen. Hierzu ist ein standardisierter Datenaustausch zwischen den Monitoring-Tools und den operativen Systemen zu etablieren. Eine weitere Anforderung ergibt sich aus der Notwendigkeit, mobil und vor Ort auf Informationen zugreifen zu können und diese zu verändern, wie bspw. bei der Mängelerfassung. Besondere Anforderungen sind hierbei die flexible Einbindung neuer Funktionalitäten und Dienste in die Architektur sowie die einfache Einbindung neuer Netzwerkpartner, was typisches Merkmal für die Domäne ist. Eine Konsolidierung der hergeleiteten Aspekte führt zu folgenden Anforderungen an die Architektur: 1. Modellierung und grafische Darstellung der unternehmensübergreifenden und unternehmensinternen Geschäftsprozesse 2. Analyse, Optimierung und Simulation der Geschäftsprozesse 3. Implementierung der Prozesse in die Systemlandschaft der Unternehmen unter Verwendung bestehender und neuer Anwendungen 4. Ausführung der Prozesse bzw. Unterstützung der Ausführung nicht automatisierbarer Prozesse, sowohl unternehmensintern als auch unternehmensübergreifend 5. Planung und Steuerung der laufenden Geschäftsprozesse Es resultieren drei Ebenen, auf denen diese Aufgaben anzusiedeln sind: das Management, die Modellierung sowie die Prozessausführung (siehe Abbildung 2). Abbildung 2. Aufgaben-Ebenen der Architektur